home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Developer CD v2.1
/
Amiga Developer CD v2.1.iso
/
DevInfo
/
DeviceDevelopment
/
NSD-Future
< prev
next >
Wrap
Text File
|
1996-10-05
|
2KB
|
52 lines
$Id: NSD-Future 1.2 1996/10/06 09:01:17 heinz Exp $
Future Directions
=================
What are the future directions for NSD? Currently the items
mentioned in the following paragraphs are under consideration. They
are phrased as suggestions to think about. Obviously, thoughtful
comments are very welcome.
It may be useful to add NSDEVTYPE_NARRATOR for the future to bring
back a narrator eventually. A future narrator may be a completely
different beast for input and output than the one that used to be
part of the OS, which means that the meaning of a device type like
this needs a lot more thought in general. So if someone has an
intention to create a narrator like NSD device, please get in
contact with us.
It has been suggested that the query result should contain the size
of the expected I/O request for general use. This would make it
possible to extend the functionality of an existing device type by
optionally extending its IORequest in agreed upon and standardized
ways without having to introduce a new type specifier. This is
tricky, though, as a single device type may have multiple valid
sizes depending on the command used, like the original
trackdisk.device. Maybe the maximum supported size should be set
here to give an indication of the maximum available request feature
size. Maybe a table of possible sizes, indicating different
features should be returned.
SANA devices pass in necessary configuration data on OpenDevice().
This is not really such a great idea within the NSD context.
A general NSD command to pass in configuration data for any device
type may be a very good and very important thing to keep
OpenDevice() close to its original meaning as hinted at in the RKM.
There should be comments on how I/O requests are correctly
duplicated. Official documentation on this has always been sketchy
at best, and the fact that for any device type basically only the
io_Device and io_Unit IORequest need to be duplicated, except for
device specific data in an extended request structure, has not been
really defined well.
This document needs to be presented in a more readable form and
possibly in hypertext form. It should also continue to be available
in plain text, though. texinfo may be a good and portable choice with
minimum environment needs, as long as illustrations are not needed.
*** EOT ***